Part 1: “Everything you wanted to know and were afraid to ask about I2P»

I have used I2P for quite some time and read all the articles about this network available on the Russian-language part of the Internet, but not one of them provides comprehensive knowledge about it. Taking into account the wishes of people in previous publications about I2P, I started translating the official source.
Due to the large amount of information, I will post translations in parts.

If anyone is really interested in this, please, under the “spoiler”».

This is not enough* art translation, I apologize if the meaning was distorted somewhere.
Send amendments and corrections in PM.
Official source: i2p2.de

Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P»
Part 2: Tunnel magic, NetDB and protocol juggling
Part 3: Digital Garlic

Introduction

I2P is a scalable, self-organizing network that distributes packets between anonymous network layers, in which any number of applications can run, while maintaining a high level of security and anonymity. Each of these applications, on their own, can be anonymous and have their own network management capabilities without having to worry about properly managing free, distributed, and asynchronous routing. I2P allows them to mix (hide - approx. lane.) your work among a large number of already existing anonymous users working on the network.
Applications can use all the capabilities of the regular Internet, while combining anonymous web surfing, web hosting, anonymous chat, file transfer, blogging and other features that will be added later.

1. Web surfing using any browser that supports proxy work.
2. Chat: IRC, Jabber, I2P-Messenger.
3. File sharing:
   Torrents: I2PShark, Robert, Imule, PyBit, I2P-bt
   Transfer directly between PCs: I2Phex
4. E-mail: susimail and I2P-Bote.
5. Blog: Using Syndie.
6. Distributed data storage, save your data using cloud Tahoe-LAFS over I2P.
7. Newsgroups using any reader that supports proxies.

Unlike websites hosted on the Freenet and GNUnet distribution networks, sites hosted on I2P are fully interactive - there are traditional web services: search engines, message boards, blogs with the ability to comment.

With all these anonymous applications, I2P takes on the role of "Charon"» (The one who transported the souls of the dead across the river in Greek mythology) — applications communicate that they want to send some data to an address represented by a cryptographic identifier (This is the destination) and I2P makes sure that the data is delivered secretly and anonymously. I2P is able to distribute packets so that information is transmitted as anonymously and reliably as possible through several streams, over TCP. At the same time, based on the algorithm, maximum throughput and minimum delays are ensured.
Several simple SOCKS proxies are available to link the existing internet to I2P, their capabilities have been limited as many sites tend to pose an anonymity threat and put the user at risk.
The only safe way is to fully process applications to ensure proper operation, we provide a number of APIs that can be used to improve the network experience (This apparently means working with the Internet in both directions - approx. lane.).

I2P is not a research, academic, commercial or government project. It is a collaborative effort between engineers to do whatever is necessary to provide a sufficient level of anonymity for those who need it. Active development has been going on since the beginning of 2003 and has occupied all the time of the developers; there is also a special group consisting of participants from all over the world, which also participated in the development. All I2P source code is open source and freely available on the website, most of the code is in the public domain, although several cryptographic procedures are used under the BSD license.
The people working on I2P do not control what people do in the client applications, and there are several applications available under the GPL license (I2PTunnel, susimail, I2PSnark, I2P-Bote, I2Phex and others.).
I2P funding comes exclusively from donations, and is not subject to taxes (oh, what a waste), since many developers themselves are anonymous.

Principle of operation

Review

To understand how an I2P network works, it is important to understand a few key concepts.:
First, I2P makes a strict separation between the software participating in the network (the "router") and the anonymous ends ("targets") associated with individual applications.
When I2P is used it is clearly visible, but what is it hiding? It hides information about what the user is currently doing (if anything at all), as well as whether the user is connected to a specific router. End users typically have multiple local addresses on the router - for example, one proxy for IRC servers, another to support a custom anonymous web server ("eepsite"), another for I2Phex for example, a fourth for torrents, etc..

The second important aspect to understand the work is the concept of the “tunnel”. A tunnel is a directed path through an explicitly selected list of routers. Multi-layer encryption is used, so each router can only decrypt one layer. The decrypted information contains the IP of the next router, along with the encrypted information that will be forwarded. Each tunnel has a starting point (the first router, also known as a "gateway") and an end point. Messages can only be sent one way. To receive the return message, another tunnel is required.



There are two types of tunnel: "outgoing" tunnels send messages from the tunnel creator, while "incoming" tunnels send a message back to the tunnel creator. The combination of these two tunnels allows users to send messages to each other. The sender (“Alice” in the image above) establishes an outgoing tunnel, while the receiver (“Bob” in the picture) creates an incoming tunnel. The gateway in the incoming tunnel can receive messages from other users and forward them to the endpoint (in this case "Bob"»).
The endpoint of the outgoing tunnel will need to send a message to the gateway in the incoming tunnel. To do this, the sender (“Alice”) adds instructions to the encrypted message. Once the outgoing tunnel endpoint decrypts the message, it will be instructed to forward the message to the correct incoming gateway (the "Bob" gateway).»).

The third important point to understand is the NetDB network database. Several algorithms designed to exchange network metadata. There are two types of metadata: "routerInfo" and "leaseSets"»:
routerInfo gives the information about routers needed to communicate between private routers (their public keys, addresses, etc.), while leaseSet gives routers the information needed to communicate between specific points.
LeaseSet contains a block of information "Lease". Each field defines a tunnel of gateways that allows it to reach the recipient. Full information contained in Lease:
Incoming gateway for a tunnel that allows it to reach the recipient.
Time when the tunnel became obsolete.
A pair of public keys to be able to encrypt messages (for sending through the tunnel and for the recipient at the destination).

Routers forward their routerInfo to netDb directly, and leaseSets are forwarded through the outbound tunnel (leaseSets should be sent anonymously to avoid correlating a router with its leaseSets).
We can combine the above concepts to create a successful network.

To create her own incoming and outgoing tunnels, Alice searches netDb to collect routerInfo. Thus, she collects lists of peers that she can use as Hop (Intermediate Points) in her tunnels. It can send a first hop message requesting a tunnel and ask the router to send a tunnel request before the tunnel is built.



When Alice wants to send a message to Bob, she first searches netDb to find Bob's leaseSet and obtain information about Bob's current incoming tunnels. She then selects one of her outgoing tunnels and sends a message down it with instructions for the outgoing tunnel endpoint to forward the message to one of Bob's incoming tunnel gateways..
When an endpoint in the outbound tunnel receives these instructions, it transmits a request message and when Bob's inbound tunnel gateway receives the request, it is forwarded down the tunnel to Bob's router.
If Alice wants Bob to reply to a message, she must pass the instruction explicitly as part of the message itself. This can be done by creating a higher layer, which is created in the threading library. Alice can also improve response time by including her latest leaseSet in the message so that Bob doesn't have to do a netDb lookup for the call when he decides to respond, but this is not necessary.



While the tunnels themselves have multi-layer encryption to prevent unauthorized access to peers within the network (the "transport layer" is encrypted itself to prevent unauthorized access to network participants).
It is also necessary to add an additional layer of encryption to hide the message from the outgoing to the tunnel endpoint and the incoming tunnel gateway. This "honest encryption" allows Alice's router to wrap multiple messages into one "garlic message" (this is the fourth aspect), encrypted along with the public key, so that the man in the middle cannot determine the number of messages and what they contain..
For a typical connection between Alice and Bob, the message will be encrypted with the public key published in Bob's leaseSet, allowing the encrypted message to be read on Bob's router without giving away the public key

Another important fact. One thing to keep in mind is that I2P is entirely message based, and that some messages may get lost along the way.
Applications on an I2P network may use their own interface to communicate and take care of their own transmission control and reliability, but most applications can work adequately using standard libraries for data transmission on an i2p network.